%% date:: [[2022-09-28]] %% # [[Backend performance testing]] Backend [[Performance Testing]] involves assessing the underlying architecture and servers of an application for robustness and quality. A common approach for Backend performance testing is to programmatically simulate virtual users of an application in a [[Load Profile]] that mimics the scenario needing to be tested. ## Benefits of Backend performance testing ### It reveals bottlenecks at the component level Front-end testing tweaks the end result, the nice UI that will ultimately be interacted with. But which application components exactly are slow, and why? Front-end testing typically won't be able to answer that. Maybe those elements are all being hosted on a server that is underpowered or overutilized. You're not going to be able to pinpoint that by just looking at requests in a browser. That stuff is hidden from our customers on purpose-- we don't want them to see all the mess! ### Shift-left and modularity Applications begin as code, and that usually means starting without a UI. Without the UI built, front-end testing can't be done, but Backend testing can-- so this means you can test earlier in the development cycle. In fact, ideally your developers are also writing unit tests for performance. The earlier that performance defects are spotted, the easier and more cost-effective it is to fix them. Backend testing lets you be more granular, in that you can target just one part of the application that is built. You don't need the entire application built to do Backend testing, and you don't need the whole environment. If an integration with another component hasn't been built yet, you can still test the component that IS built, mocking up responses it would expect to receive from the other component that ISN'T built. Backend testing lets you do system testing as features are being created. ### It replicates behavior under load Front-end excels at optimizing a single user's experience of an application. You CAN use front-end tools to load test the Backend, too, but those tools are typically very resource-intensive by their very nature, so it can be significantly more expensive to do that. We spend a lot of time making sure that the test environments we're using for our tests are as close to the real thing as possible: we want the same application logic, the same interface, and the same integrations. But load is part of that, at least for most public-facing applications. Backend testing lets you see how the user's experience degrades when there are many others doing the same things at the same time. It also lets you see how well your application responds to that increased demand. It's like the ultimate dress rehearsal. ### Better failure handling It's hard to induce significant failures in front-end testing that affect ALL or most users, because if we can induce it at that point, from the interface, then so can our users! In Backend testing, the access we have to the things "under the hood", so to speak, let us also run more interesting experiments on our application. We can purposely create catastrophic scenarios to see how quickly or gracefully the application recovers. Backend performance testing also helps us identify issues that arise from structural or architectural decisions. Maybe we should consider using a Kubernetes cluster for a particularly vital part of the application, or maybe we should use a CDN to distribute our resources instead of serving them directly from our application servers in one country. Backend testing lets us test assumptions about how the application is built and gives us data to decide whether or not we want to change it. ## Concerns in Backend testing - Time: Backend testing is more complex and can thus take longer than front-end testing. - Environment: Backend testing is commonly believed to require a production-like environment, but this isn't always true. - Lack of expertise: Backend performance testing is often thought of as a dark art requiring specialized performance testers to carry out. - Budget: Some Backend performance testing solutions are infamous for being extremely expensive. ## Types of Backend performance testing Performance testing verifies the following aspects of an application: #### [[Scalability]] *Can the system adjust to steadily increasing levels of demand?* Scalability is the ease with which an application can cope with increased demand. #### [[Elasticity]] Elasticity is the ability to adapt to circumstances, including scaling down when possible to save on resources and costs. #### [[Availability]] Availability involves a system's uptime and resilience against outages. #### [[Reliability]] Reliability is the consistency of an application's behavior, especially when handling environmental and application-level failures. #### [[Resiliency]] Resiliency is the application's ability to withstand both expected and unexpected events in production. #### [[Latency]] The latency of an application is how quickly it processes requests and returns the processed output to a user. - Database Tuning: Optimizing a database to avoid processing delays - Component testing: Sending requests to individual components to ensure speedy processing. - [[Load Testing]]: Simulating load on servers to find bottlenecks. ## Load testing and Backend performance testing Load testing, in the sense of generating load rather than in the sense of generating _peak_ load, has become practically synonymous with Backend performance testing. This is mainly because the term "load" can be a catch-all for dramatically different types of traffic. Treating load testing as the same thing as Backend performance testing is problematic because it implies that testing the Backend requires volume. The truth is that load testing is merely *one method* of testing. ## See also - [[Performance testing with Cypress, Lighthouse, and k6]]